A method according the related art with respect to a design flow is shown in FIG. 1. FIG. 1 shows a known method of creating and programming a reconfigurable architecture in the sense of the remarks below. The figure shows on the right that a library containing modules for a larger chip is provided, which concerns, among other things, an ALU-PAE definition, a RAM-PAE definition etc. As required and specified, these different definitions are combined in an XPP generator and afterwards a synthesis is performed for the output obtained from the XPP generator in order to generate a mask set for the synthesized hardware on the basis of the result of the synthesis such that a chip may be produced.
The left side of the diagram shows a library for a number of programs (software parts) in a language such as NML, this special language being known from other publications of the applicant. Then a program is written by using such library software parts, it being obviously possible to use additionally and/or exclusively also software parts not contained in the library. The program is then compiled, compiling here being understood to include also placing and routing, as required. For this purpose, the compiler needs information that refers to the actual target hardware design. The compiler also has such information. The configuration(s) generated by the compiler are than made to run on the hardware as run time configuration.
It has alsoalready been proposed (WO 2004/114166) to provide a so-called bottom-up approach in hardware design, an integrated circuit development system having been provided, which included a description library of a multitude of hardware objects, which are each structured to operate on message packets, each object being intended to have relatively similar electrical load characteristics; and the integrated circuit development system further including a modeler, which refers to the library and is to be structured to accept an instruction that creates an instantiation of one of the descriptions and to accept a command that combines two or more of the created instantiations with one another. The laborious programming of this known method of instantiated hardware objects then provides for a collection of software objects to be accepted which are themselves to be abstractions of the instantiated hardware objects, each software object being intended to include a list of hardware objects that are used in the software object as well as a list of rules for combining the listed hardware objects and an instruction file that is to be loaded into the listed hardware objects; a description of the collection of physically instantiated hardware objects then having to be accepted; an identifier having to be allocated to each of the physically instantiated hardware objects from the list of hardware objects and an initialization file having to be created for the collection of physically instantiated hardware objects by using the identifier in order to replace symbolic information in the instruction files. The last-mentioned technique as shown in WO 2004/114166 is disadvantageous particularly because of the fact that it can neither be assumed with absolute reliability that a hardware-software isomorphism is actually given and not merely claimed, and because in addition the applications designed in accordance with the system must often provide for an excess of unnecessary hardware on a silicon chip. At the same time there is no assurance that in the known procedure according to WO 2004/114166 an optimal execution speed of the hardware objects tied together from predefmed, invariable hardware modules is realized.
Furthermore, in the cited related art as shown in WO 2004/114166, it remains necessary for hardware engineers to design the hardware. It is not possible to leave the construction of a chip for a dedicated application to the programmer of the dedicated application entirely or at least largely.